0.9.0: prompt version 7, actions that fit the envelope - #10

0.9.0: prompt version 7 shows each building what the envelope allows this hour, so replies can fit it. The envelope is unchanged from 0.8.0. The estimates below were made from recorded runs and the scripted strategy before any live call; the live month follows them.

Live results (claude-haiku-5-5, full month, 719 hours, prompt version 7, run 20261023T135430Z; rule-based run 20261022T162847Z)

• Clamped hours fell from 312 to 27 because version 7 shows the agent its allowed range each hour. 250 of the 0.8.0 clamps were held trims the envelope logged as clamps, not the agent breaking a limit.
• Ramping is under 1.0 for the first time since 0.4.0. Daily peak and all-time peak are the best of any live run. Load factor (0.9566) is second only to 0.4.0 live (0.9559), which left comfort at the baseline.
• Against 0.8.0 it gives back a little cost (0.9245 against 0.9190), emissions (0.9648 against 0.9610) and comfort (0.0940 against 0.0769).
• It beats or ties the rule-based controller on every KPI except hot-side discomfort, which trails by 0.0005. Outage unserved energy now ties the baseline.
• Valley filling stays off by default: it cut tuning-set ramping further but cost about 0.01 in cost.
• 719 model calls, 0 fallbacks, $0.4607 of $2.00, replay 719 of 719 hours deterministic. The published viewer now shows this run.

Why 0.8.0 live was clamped in 312 of 719 hours

• 345 of the 390 clamps were the trim hold. 250 of those were null on a held trim, which the version 6 prompt said keeps it: the envelope kept it and logged a clamp. 52 ended a trim without end_trim, 38 eased too fast, 5 asked for a trim where the hold had ended. None deepened a trim when it should hold (deeper is allowed).
• 21 of the 32 comfort clamps were rounding under 0.002.
• Fitting the month's own replies into the version 7 ranges leaves 7 clamped hours with the same KPIs to four decimals. Six are hours where the held trim is deeper than the baseline cooling, which no reply can avoid; one is a peak limiter trim.

Why ramping stayed above 1.0 in 0.8.0 (points above 1.0, 0.4.0 live against 0.8.0 live): battery charging +1.24 against +1.90, discharging -1.59 against -2.01, cooling trims 0.00 against +0.86, other 0.00 against +0.01. The agent sent strategy_battery in 1,994 of 2,157 building hours. Following it in the other 163 too gives ramping 0.9884.

Changes

• Prompt version 7 (default). Per building: trim (depth, state, why, min_depth, end_trim_ok), cooling_range, battery_range and last_clamp. null is now described as exactly the baseline. The ranges are computed read only from the envelope's state. A randomized test checks that any value inside them passes unclamped. Version 6 stays selectable.
• Battery guidance. A soft cap and valley filling were searched on the tuning months (36 settings). None lowered ramping without raising cost or the all-time peak, so the shipped plan is version 5's. The prompt instead asks the agent to send strategy_battery as given, to stay within 0.1 of it when it differs, and never to skip a peak-shaving discharge.
• scripts/evaluate_fit.py, scripts/tune_strategy.py --version 7, the scripted version 7 strategy, and tests. One test pins EnvelopeConfig to 0.8.0 field by field. Another replays the 0.8.0 live month 719 of 719 when it is on disk.
• README and CHANGELOG carry the live results; the CHANGELOG's 0.8.0 heading is restored.

Estimates made before the live run, phase 2 month

Version 7 requests are 1.7 percent smaller than version 6 (10,748 against 10,928 characters).

Tests: 237 passed. Repo checks passed.